Autonomous Underwater Vehicles : T-REX Autonomy testing process
This page last changed on May 29, 2009 by tm.
How to test T-REX
First see our configuration of hosts that we use for testing shore-side and at sea below.
Fig. 1
There are a 4 levels of testing that we use.
- P-Sim: The Pseudo-Sim uses a crude dynamics model of the vehicle within T-REX and provides a first cut on testing T-REX domain models. This allows us to prune egregious modeling errors right away, is fast and works on Mac OS as well as RHEL.
- F-Sim: is the newly developed fastSim facility which runs only on Linux with the new AUV-Linux code base at approx. 160X real-time. The objective with this sim is to get a first cut on how accurate the T-REX models are w.r.t actual vehicle dynamics encoded in the simulator ported over from the original QNX code. To date, the best way to run this is by using the 'dorado1' account on threadfish.
- Q-Sim: is the real-time QNX version of the simulator which provides an accurate version of T-REX behavior when at sea. Like the F-Sim (derived from the auv sim code), there are also a few parameters one can tweak to mimic environmental changes that T-REX can respond to (e.g sub-surface currents and location drop offs during deployment). The modus-operandi is to use an EPIC stack (trex1/trex3) and mimic the client/server approach used by T-REX at sea with a QNX desktop (saumon/foobar).
- V-Sim: is a new appraoch suggested by Hans to get as close to the vehicle, run the drivers without actually using the physical science instruments. This involves setting up the $AUV_CONFIG_DIR/devices.cfg file with simulated instrument drivers but done on the CTD vehicle with the magnet taken out to simulate actual conditions.
In addition, we use two other approaches to shore side testing which have tested T-REX models sufficiently effectively to point to bugs. They are
- Monte-Carlo methods: which takes a number of variables and makes repeated runs of T-REX using a uniform sampling distribution for the values of these targeted parameters and run either on Mac OS or RHEL. MC often helps to shake out how robust T-REX is w.r.t environmental variability; however passing all MC tests does not imply that T-REX is fully covered when it comes to surprises in the real-world.
- Stepped Sim: which allows debugging by stepping thru T-REX similar to what gdb does functionally. This is used especially when there are issues with the T-REX or EUROPA (planner) core.
To build and test T-REX it is best to use an existing version of the source tree from SVN. The reason is that there are a number of branches which one has to be aware of to ensure that the right one is indeed being used to test.
Currently, dorado1@threadfish:~/coding/ has two versions; the HEAD and code for the Front following mission. To test Q-Sim one should follow the steps below:
Assuming you have the right versions checked out from CVS and SVN on Threadfish, do:
- For the NAL Iridium driver, Move to the auv-linux directory and checkout the tagged baseline and build
- cd ~/coding/auv-linux
- cvs up -r "april27-2009" (or whaterver the correct tag is supposed to be)
- cd onboard
- make
- % cd <to the TREX directory>
- % svn update (to update the TREX tree)
- % export ROOT_DIR=`pwd` (if the directory is not the default such as for the Front following hierarchy)
- % . devConfig (to source all the env. variables needed)
- % jam (Note: jam clean will clean the Europa tree (a bug), if this jam make fails, then build Europa before running).
- % cd ctd2007 (which contains all the model and configuration files for T-REX)
- % jam samp sim batcher amc (to ensure you generate the necessary binaries; to run on Q-Sim you will need to generate only the amc binary)
- % cd ../deploy/
- Ensure that the T-REX binaries are targeted to run on the right shore-side stack you want (trex1 or trex3). The default is trex1; to change do
- export AMC_TARGET=dorado1@trex3
- % ./deploy.exec (this and the following command will ask for a passwd to copy over a gzipped tarball)
- % ./deploy.missions
- Now move to the target stack (ex. trex3) and log in as 'dorado1'
- % cd amc
- % . config.amc (to set up the environment)
- % ./install.amc all (you can also selectively install one of the above two tar balls)
- % cd missions
- This step requires some apriori knowledge of which mission is being run because of the way configuration files alter the way T-REX can be put together for the mission. There are two files that are at issue: amc.cfg which indicates how T-REX is put together and vcs.cfg which indicates which server host is being connected to where VcsServer is being run.
- In this case, since we're dealing with testing, either foobar or saumon are the likely targets. Therefore in the 'remoteName' keyword in vcs.cfg, change the name of the server to one of the latter.
- To alter the amc.cfg file, simply copy over the 'right' cfg file on top. For the Front following mission, since we need a downlink reactor within T-REX you will need amc.vcs.dl.cfg. so
- % cp amc.vcs.dl.cfg amc.cfg
- You're set with configuring the T-REX client. So move over to the QNX desktop to fire up the VcsServer. Assuming here foobar
- telnet foobar (use the 'ansi' terminal setting)
- $ cd auv_autonomy (since our version of the QNX layered control requires VcsServer and Statepublisher, this copy is different from the nominal version that Hans maintains. This version should be checked with what is being run by Hans on the vehicle ever so often to ensure we're in sync.)
- $ . configSrc (to set up the environment)
- Double check to see that a stray VcsServer from a perious run isn't still running using 'ps'
- $ ps -a
- Ensure that Mqueue is indeed running. And if not then do
- $ su root
- $ Mqueue&
- $ cd $AUV_CONFIG_DIR (if you want to tweak the virtual environment in simulator.cfg)
- if so, then you can tweak depth1/depth2/depth3 and northCurrent and eastCurrent variables
- Make sure that the state publisher is visible to the client. In the $AUV_CONFIG_DIR make sure in statePublisher.cfg
- the IP address of the correct client is uncommented with AMC_IP
- QNX behaves strangely with large files. Often from a previous run, the VcsServer.log files in $AUV_LOG_DIR, are corrupted. The consequence is that when you try to run VcsServer, it will abort without an explanation. To recover do
- $ su root
- $ df (to get all the partitions)
- $ chkfsys <file partition name> will often fix it.
- $ cd $AUV/bin
- $ ./vcsServer -v -sim& (to fire up the vcs server)
- In most cases you'd want to run the setup for a long time when connection with the QNX terminal is not critical. If so then run the above with a 'nohup' pre-pended.
- Move back to the T-REX stack to fire up the T-REX client
- % ../exec/amc_o_rt <Mission Config file> & (where Mission Config file is mission dependant; e.g for Front following it is front.cfg). Also as above, the nohup can be prepended.
- The above should nominally get T-REX to initiate the socket connection with the server and start doing its thing. To observe, you can
- % tail -f ../log/latest/TREX.log
- % tail -f ../log/latest/TREX.log
VSIM Procedure
This procedure is run on the vehicle with simulation on the navigation drivers and as many real instrument drivers as possible. Also, the magnet should be removed to enable the batteries.
- Power-up the vehicle
- Login on mvc-dmo1 (QNX) and power up the trex2 CPU
- % ping mvc-dmo1
- % telnet mvc-dmo1 (dorado1)
- % cd home/dorado1/auv_autonomy
- % . configSrc (Setup env vars)
- % qtalk -m /dev/ser13 !a<enter>, ctrl-a x to exit (to turn on trex2 cpu)
- Wait about 90 seconds for trex2 boot (ping trex2)
- On mvc-dmo1, verify the devices.cfg is set correctly
- in the telnet to mvc-dmo1,
- % cd $AUV_CONFIG_DIR
- % cp devices.vsim.cfg devices.cfg
- % cat statePublisher.cfg (Make sure that the state publisher is visible to the client.
- the IP address of the correct client (trex2) is uncommented with AMC_IP
- Double check to see that a stray VcsServer from a perious run isn't still running using 'ps' . Also make sure Mqueue is running.
- $ ps -a
- in the telnet to mvc-dmo1,
- In another terminal window (Term 2), login to trex2: % ssh dorado1@trex2* *
- [dorado1@trex2 ~]$ cd amc
- [dorado1@trex2 amc]$ . config.amc
- Check the Iridium Modem
- % minicom iridium (dev/ttyS0 9600 8N1)
- type "AT" when minicom starts, should return "OK"
- if the A3LA iridium modem does not respond, switch back to Term1 (mvc-dmo1 qnx)
- bash-2.00$ cd $AUV/bin
- bash-2.00$ reset_a3la (toggle modem power)
- Switch back to Term2 (trex2) minicom session
- AT should retrun OK
- AT+SBDI should return +SBDI 0,1285,0,0,0 (or something similar)
- exit minicom
- % minicom iridium (dev/ttyS0 9600 8N1)
- Build and deploy from threadfish
- Now move to trex2 and log in as 'dorado1'
- % cd amc
- % . config.amc (to set up the environment)
- Test the iridium (nal) driver - open two terminal sessions on trex2
- In Term 3:
- [dorado1@trex2 amc]$ nal -dev /dev/ttyS0
- should see startup, and then: [AuvApplication] run() - just sleeps by default
- In Term 2:
- [dorado1@trex2 amc]$ cd $AUV_HOME/onboard/devices/iridium/tests
- [dorado1@trex2 tests]$ storefwdclient -f test-a3la.sbd
- Observe the nal driver output in Term3 and also examine modem.log
- test the 'uplink' by running the Matlab script (TODO: add procedure for this)
- check email by subscribing to auvsbd@mbari.org at mbari listserver (or checking the archive on the list server)
- when finished terminate nal with ctrl-c and delete modem.log % rm modem.log
- In Term 3:
- in Term3 Start the nal driver for the vsim test
- [dorado1@trex2 amc]$ nohup nal -dev /dev/ttyS0 &
- [dorado1@trex2 amc]$ tail -f nohup.out (check the nal driver is running - look for [AuvApplication] run() - just sleeps by default)
- Test the modem with a text file
- [dorado1@trex2 tests]$ storefwdclient (enter a meaningful test message and then wait)
- tail -f nohup.out in Term3 or tail -f modem.log
- If the storefwdclient fails to send the message, start storefwdclient again with no messages (enter, enter)
- A successful message from Term2 (storefwdclient looks like:
"StoreAndForward.Downlink succeeded" payload: This is Thom running VSIM at 2:45 on 2 May 2009
Got StoreAndForward event: ConnectModem complete
Done.
terminate called after throwing an instance of 'omni_thread_fatal'
- In the telnet session to mvc-dmo1, start the vcsServer
- % cd $AUV/bin
- % nohup ./vcsServer -v &
- In Term2 (trex2), make sure the config file is correct for vsim
- % [dorado1@trex2 tests]$ cd ~/amc/missions
- % cp amc.vcs.dl.cfg amc.cfg
- Verify amc.cfg and vcs.cfg have the correct settings (remote name, IP address)
- In Term1 (mvc-dmo1), startup the vcsServer
- $ nohup ./vcsServer -v & (to fire up the vcs server)
- In Term2 Move back to the T-REX stack to fire up the T-REX client
- [dorado1@trex2 missions]$ nohup ../exec/amc_o_rt front.cfg & (For the time being, mission file is front.cfg).
- The above should nominally get T-REX to initiate the socket connection with the server and start doing its thing. To observe, you can
- % tail -f ../log/latest/TREX.log
- in Term1, bash-2.00$ ps -a
PID PGRP SID PRI STATE BLK SIZE COMMAND 17 7 0 24f RECV 0 632K (//9/bin/Dev32) 22 7 0 10r RECV 0 216K (//9/bin/Pipe) 24 7 0 20r RECV 0 160K (//9/bin/Dev32.ser) 25 7 0 20r RECV 0 160K (//9/bin/Dev32.ser) 26 7 0 20r RECV 0 300K (//9/bin/Dev.ctiser) 27 7 0 20r RECV 0 440K (//9/bin/Dev32.ansi) 31 7 0 9o RECV 0 148K (//9/bin/Dev32.par) 32 17 0 20r RECV 0 316K (//9/bin/Dev32.pty) 36 4 0 10o RECV 0 18272K (//9/bin/Fsys.floppy) 37 7 0 10o RECV 0 56K (//9/bin/Iso9660fsys) 40 7 0 20o RECV 0 20K (//9/bin/nameloc) 41 7 0 20o REPLY 0 16K (//9/bin/nameloc) 43 7 0 10o RECV 0 120K (//9/bin/Dosfsys) 45 7 0 23r RECV 0 336K (//9/bin/Net) 47 7 0 20r RECV 0 348K (//9/bin/Net.ether82557) 48 7 0 20r RECV 0 56K (//9/bin/Net.ether1000) 87 7 0 10o WAIT -1 28K (//9/bin/tinit) 90 7 0 10o RECV 0 20K (//9/bin/tinit) 91 7 0 14o RECV 0 68K (//9/bin/Mqueue) 28928 28123 2 10o REPLY 0 36K supervisor -plan AmcPlan.cfg -dyno 28942 28123 2 10o REPLY 22 16K tee -i /home/dorado1/auv_autonomy/auv/altex/onboard/logs/latest/syslog 28951 28123 2 10o RECV 0 28K eventLogServer 28953 28123 2 18o RECV 0 64K workSite 22812 28123 2 14o RECV 0 72K vehicleConfigurationServer 28959 28123 2 10o RECV 0 32K externalCommsServer 28963 28123 2 14o RECV 0 112K navigationServer 22820 28123 2 10o RECV 28983 32K externalComms 28968 28123 2 10o RECV 0 140K layeredControl erver -dyno -plan AmcPlan.cfg -abort 28970 28123 2 18o RECV 0 132K navigation 28972 28123 2 14o RECV 0 56K dynamicControlServer 28973 28123 2 14o RECV 0 176K layeredControl -dyno -plan AmcPlan.cfg -abort abortMplan.cfg 28985 28123 2 14o RECV 0 148K simulator 22331 28123 2 14o RECV 0 28K simTailCone 22333 28123 2 18o RECV 0 32K simAhrs 28991 28123 2 18o RECV 0 72K simGps 28993 28123 2 18o RECV 0 28K simDepthSensor 2375 28123 2 10o RECV 0 60K seabirdServer -n CtdIFServer -dev tcp:sci1-dmo1:10001 22857 28123 2 10o RECV 0 60K seabirdServer -n ctdDriver2 -dev tcp:sci1-dmo1:10002 29003 28123 2 10o RECV 29009 92K seabirdDriver -n CtdIFServer -serial tcp:sci1-dmo1:10001,9600,8,n,1 29004 28123 2 10o RECV 29010 92K seabirdDriver -n ctdDriver2 -serial tcp:sci1-dmo1:10002,9600,8,n,1 22862 28123 2 18o RECV 0 48K simDvl 29011 28123 2 10o RECV 0 48K dropWeightServer -dev /dev/ser13 22869 28123 2 10o RECV 0 64K statePublisher 22872 28123 2 10o REPLY 17 52K dropWeight -serial /dev/ser13,9600,8,n,1 28125 28123 2 10o RECV 28926 64K ./vcsServer -v [1]+ Exit 221 nohup ./vcsServer -v
Hardware-in-the-loop Test
Open 4 terminal sessions
Term1:
telnet mvc-dmo1
bash-2.00$ cd /home/dorado1/auv_autonomy
bash-2.00$ . configSrc
bash-2.00$ qtalk -m /dev/ser13
!a<enter> (look for gulperFB=1), then ctrl-a, x
Term2:
ping trex2 (waiting for the boot)
ssh trex2
[dorado1@trex2 dorado1]$ cd amc (/home/dorado1/amc)
[dorado1@trex2 amc]$ . config.amc
[dorado1@trex2 amc]$ cd missions
[dorado1@trex2 missions]$ cat vcs.cfg
<!-- Configuration file used byt VCS/CORBA adapter and others to -- -- declare the timelines which interface with the vehicle and other -- -- parameters. Note : the remoteName should preferably be by default (at least -- -- on svn) mvc-dmo1 other attributes of the main tag ashould _not_ -- -- be changed ! (except you know exactly what you are doing) --> <Config log="1" localPort="8002" remoteName="mvc-dmo1" remotePort="8004" missionStart="init.cfg"> <Timeline name="vehicleState" command="0" /> <Timeline name="setpoint" class="Setpoint" command="1" /> <Timeline name="descend" class="Descend" command="1" /> <Timeline name="ascend" class="Ascend" command="1" /> <Timeline name="waypoint_yoyo" class="Waypoint" command="1" /> <Timeline name="getgps" class="GPS" command="1" /> <Timeline name="FireTheGulperAMC" class="Gulper" command="1" /> </Config>
[dorado1@trex2 missions]$
[dorado1@trex2 missions]$ cat amc.cfg
<!-- This file is the basic configuration for: - connecting to the auv (QNX or Linux) - and send/receive messages through the iridium modem. As fo now the connect is set to 1 by default as this file should be used on "real" conditions. --> <Config> <!- Use this component when running onboard -> <TeleoReactor name="vcs" component="VCSAdapter"/> <TeleoReactor name="exec" component="DeliberativeReactor" lookAhead="5" latency="1" solverConfig="exec.solver.cfg"/> <TeleoReactor name="downlink" component="Downlink" lookAhead="1" latency="0" log="1" connect="1" config="downlink.cfg"/> <!- Skipper has 10 Hour lookahead. -> <TeleoReactor name="skipper" component="DeliberativeReactor" lookAhead="36000" latency="60" solverConfig="skipper.solver.cfg"/> </Config>
Term3:
slogin trex2 (or ssh trex2)
[dorado1@trex2 amc]$ cd amc
[dorado1@trex2 amc]$ . config.amc
[dorado1@trex2 ~]$ minicom iridium
Then type "AT" and look for "OK" (no quotes)
If the vehicle has just been powered up, there is no response so you'll need to enable the A3LA modem power
Term1:
Switch back to Term1 (QNX mvc-dmo1) to toggle the modem power
bash-2.00$ cd $AUV/bin
bash-2.00$ reset_a3la
Term3:
Switch back to Term3 where minicom is running and type "AT", sometimes it says ERROR, just type AT again
Here's a sample of the minicom session:
Welcome to minicom 2.1
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jul 26 2006, 06:38:09.
Press CTRL-A Z for help on special keys
ERROR
OK
+SBDI: 0, 1602, 0, 0, 0, 0
OK
type ctrl-a, then x to leave minicom
Term4 (trex2):
[dorado1@trex2 ~]$ cd amc
[dorado1@trex2 amc]$ . config.amc
[dorado1@trex2 amc]$ cd $AUV_HOME/onboard/bin
[dorado1@trex2 auv-linux]$ pwd
/home/dorado1/auv-linux/onboard/bin
[dorado1@trex2 bin]$ nohup ./nal -dev /dev/ttyS0 &
[1] 1968 [dorado1@trex2 bin]$ nohup: appending output to `nohup.out'
[dorado1@trex2 bin]$ tail -f nohup.out
terminate called after throwing an instance of 'omni_thread_fatal' Reading log4cxx configuration file "/home/dorado1/auv-linux/onboard//sampleConfig/log4cxx.cfg" 14:20:15.598 DEBUG [NALDriver] read +GCMI response 14:20:15.623 INFO [NALDriver] manufacturer: OK 14:20:15.623 INFO [NALDriver] initialize() complete IOR:010000001a00000049444c3a6175762f53746f7265416e6446776449463a312e300<snip>000 14:20:15.643 DEBUG [NALApp] Leaving NALApp.initialize() 14:20:15.644 INFO [AuvApplication] run() - just sleeps by default
Then tail the modem.log
[dorado1@trex2 bin]$ cd $AUV_LOG_DIR
[dorado1@trex2 logs]$ tail -f modem.log
In Term3:
[dorado1@trex2 bin]$ storefwdclient (type in a descriptive test string like "This is the vehicle on the zephyr hardware in the loop test by Thom")
Check to see that the email arrived, [auvsbd] SBD Msg From Unit: 300003000227440, with an *.sbd as attachment. Open the attachment with a text editor to verify the message
In Term1:
bash-2.00$ cd $AUV_CONFIG_DIR
bash-2.00$ cp devices.test.cfg devices.cfg
In Term2 (trex2 in missions dir)
Verify the settings in init.cfg
[dorado1@trex2 missions]$ pwd
/home/dorado1/amc/missions
[dorado1@trex2 missions]$ cat init.cfg
behavior missionTimer {
timeOut = 26000;
}
behavior depthEnvelope {
minDepth = 0;
maxDepth = 175;
abortDepth = 185;
abortAltitude = 15.0;
}
behavior setpoint {
id=0;
heading=0;
speed=0.0;
verticalMode=pitch;
pitch=0;
duration=60;
In Term1 (mvc-dmo1):
bash-2.00$ cd $AUV/bin
bash-2.00$ nohup ./vcsServer -v &
[1] 8344
bash-2.00$ ps -a
8346 8344 2 10o REPLY 82 64K ./vcsServer -v [1]+ Exit 154 nohup ./vcsServer -v bash-2.00$ cd $AUV_LOG_DIR bash-2.00$ ls 2009.117.00/ 2009.119.00/ latest@ 2009.118.00/ 2009.119.01/ nov.13th.vcs.tar 2009.118.05/ CVS/ testLogs/ 2009.118.06/ VcsServer.log.0
bash-2.00$ cd ../logs
bash-2.00$ tail -f VcsServer.log.0
In Term2:
[dorado1@trex2 missions]$ nohup ../exec/amc_o_rt msg.timing.1.cfg &
[dorado1@trex2 missions]$ cd ../log/
[dorado1@trex2 log]$ tail -f latest/TREX.log
bash-2.00$ tail -f VcsServer.log.0
62940673.813,
######################### Wed Apr 29 21:31:13 2009
62940673.943, VcsServer -- configuration:
Port = 8004 ms
62940673.943, VcsServer: Socket created on fd 6
62940673.993, VcsServer - running
62940853.801, VcsServer: Connected to client on 134.89.32.39
62940853.801, VcsServer[t=0, delta=0]: Grabbing data
62940853.981, VcsServer:initMission:
behavior missionTimer {
timeOut = 26000;
}
behavior depthEnvelope {
minDepth = 0;
maxDepth = 175;
abortDepth = 185;
abortAltitude = 15.0;
}
behavior setpoint {
id=0;
heading=0;
speed=0.0;
verticalMode=pitch;
pitch=0;
duration=60;
}
62940854.331, VcsServer::initMission() - starting supervisor
62940855.371, VcsServer::openLC() - created IF with LayeredControl
62940855.671, VcsServer[t=1.86987, delta=1.86987]: Grabbing data
62940891.739, VcsServer: ack - STARTED:0
62940952.044, VcsServer::handleLCMessages() - AMC mission started
62940952.044, VcsServer: ack - FINISHED:0
62941028.259, VcsServer: ack - FINISHED:5167
62941033.779, VcsServer: handling insertBehavior
62941034.039, VcsServer: ack - STARTED:6226
62941037.969, VcsServer[t=184.167, delta=0.43997]: Grabbing data
<snip>
62941045.198, VcsServer: ack - FINISHED:6226
62941052.248, VcsServer: No ping received for 7 of up to 12 seconds
62941053.058, VcsServer: No ping received for 8 of up to 12 seconds
62941054.137, VcsServer: No ping received for 9 of up to 12 seconds
62941055.217, VcsServer: No ping received for 10 of up to 12 seconds
62941055.697, VcsServer::recvString - received 0 bytes when expected 4 (uint32_t) !!!
62941055.697, Received a NULL message : should no happen.
bash-2.00$ ps -a
PID PGRP SID PRI STATE BLK SIZE COMMAND 8707 8344 2 14o RECV 0 60K dynamicControlServer 17 7 0 24f RECV 0 632K (//9/bin/Dev32) 8726 8344 2 14o RECV 0 176K layeredControl -dyno -plan AmcPlan.cfg -abort abortMplan.cfg 23 7 0 10r RECV 0 32K (//9/bin/Pipe) 24 7 0 20r RECV 0 160K (//9/bin/Dev32.ser) 25 7 0 20r RECV 0 160K (//9/bin/Dev32.ser) 26 7 0 20r RECV 0 300K (//9/bin/Dev.ctiser) 27 7 0 20r RECV 0 440K (//9/bin/Dev32.ansi) 31 7 0 9o RECV 0 148K (//9/bin/Dev32.par) 32 17 0 20r RECV 0 316K (//9/bin/Dev32.pty) 36 4 0 10o RECV 0 18272K (//9/bin/Fsys.floppy) 37 7 0 10o RECV 0 56K (//9/bin/Iso9660fsys) 40 7 0 20o RECV 0 20K (//9/bin/nameloc) 41 7 0 20o REPLY 0 16K (//9/bin/nameloc) 43 7 0 10o RECV 0 120K (//9/bin/Dosfsys) 45 7 0 23r RECV 0 336K (//9/bin/Net) 47 7 0 20r RECV 0 348K (//9/bin/Net.ether82557) 48 7 0 20r RECV 0 56K (//9/bin/Net.ether1000) 8754 8344 2 18o RECV 0 132K navigation 8756 8344 2 14o RECV 0 64K newTailConeServer -dev /dev/ser3 8758 8344 2 18o RECV 0 60K m3dmgx1Server -dev /dev/ser12 -useForNav 8761 8344 2 19o REPLY 0 96K newTailConeDriver -dev /dev/ser3,9600,8,n,1 8762 8344 2 18o RECV 0 48K gpsServer -r ashtech -dev /dev/ser7 8766 8344 2 10o RECV 0 88K m3dmgx1 -serial /dev/ser12,9600,8,n,1 8767 8344 2 10o RECV 0 60K parosciServer -dev /dev/ser5 8772 8344 2 10o RECV 8791 60K ashtechDriver -serial /dev/ser7,9600,8,n,1 8773 8344 2 10o RECV 0 60K seabirdServer -n ctdDriver -dev tcp:sci1-dmo1:10001 8774 8344 2 19o REPLY 17 84K parosci -serial /dev/ser5,9600,8,n,1 8778 8344 2 10o RECV 0 60K seabirdServer -n ctdDriver2 -dev tcp:sci1-dmo1:10002 8779 8344 2 10o REPLY 82 92K seabirdDriver -n ctdDriver -serial tcp:sci1-dmo1:10001,9600,8,n,1 8782 8344 2 10o REPLY 82 92K seabirdDriver -n ctdDriver2 -serial tcp:sci1-dmo1:10002,9600,8,n,1 8793 8344 2 10o RECV 0 52K bluefinBattServer -dev /dev/ser10 8796 8344 2 18o RECV 0 52K dvlServer -dev /dev/ser6 94 7 0 10o WAIT -1 28K (//9/bin/tinit) 8799 8344 2 10o REPLY 0 68K bluefinBattDriver -dev /dev/ser10 98 7 0 10o RECV 0 20K (//9/bin/tinit) 99 7 0 14o RECV 0 68K (//9/bin/Mqueue) 8804 8344 2 10o REPLY 17 80K dvl -serial /dev/ser6,9600,8,n,1 8806 8344 2 10o RECV 0 48K dropWeightServer -dev /dev/ser13 8814 8344 2 10o RECV 0 64K statePublisher 8818 8344 2 10o READY 52K dropWeight -serial /dev/ser13,9600,8,n,1 8346 8344 2 10o REPLY 0 64K ./vcsServer -v 8658 8344 2 10o REPLY 0 36K supervisor -plan AmcPlan.cfg -dyno 8667 8344 2 10o REPLY 23 16K tee -i /home/dorado1/auv_autonomy/auv/altex/onboard/logs/latest/syslog 8675 8344 2 10o RECV 0 28K eventLogServer 8677 8344 2 18o RECV 0 64K workSite 8679 8344 2 18o RECV 0 72K vehicleConfigurationServer 8682 8344 2 10o RECV 0 32K externalCommsServer 8686 8344 2 14o RECV 0 112K navigationServer 8688 8344 2 10o RECV 8760 32K externalComms 8690 8344 2 10o RECV 0 140K layeredControl erver -dyno -plan AmcPlan.cfg -abort
bash-2.00$ slay supervisor
bash-2.00$ ps -a
In Term2 (trex2):
Verify that amc_o_rt has terminated
[dorado1@trex2 log]$ ps -elf | grep amc
0 R dorado1 2040 1761 0 78 0 - 975 - 14:45 pts/0 00:00:00 grep amc
Verify that TREX did not have a problem (relax in the log is BAD)
[dorado1@trex2 log]$ grep relax latest/TREX.log
[dorado1@trex2 log]$
Before turning off the power to the vehicle, shutdown the OS on TREX2 and mvc-dmo1 to prep for power off
[dorado1@trex2 logs]$ su root
Password:
[root@trex2 logs]# /sbin/shutdown now
Broadcast message from root (pts/2) (Wed Apr 29 14:48:07 2009):
The system is going down to maintenance mode NOW!
[root@trex2 logs]#
In Term1:
bash-2.00$ su root
bash-2.00# shutdown -b
Testing goal posting through iridium
starts the mission msg.timing.1.cfg
[dorado1@trex2 missions]$ ../exec/amc_o_rt msg.timing.1.cfg
look for the creation of the pipe on TREX.log
[dorado1@trex2 missions]$ tail -f ../log/latest/TREX.log | grep listening
[downlink] listening to "msg.timing.1.downlink" (fid=<a number>)
The pipe msg.timing.1.downlink (naming convention is <name of the mission>.downlink) has been created in the directory where TREX has been started (in this case ~/amc/missions). You can then send the goal through this pipe. Create a file goal.sbd with following content :
<Goal on="front" predicate="Front.Info"> <Assert name="depth"><value type="float" name="17"/></Assert> <Assert name="temperature"><value type="float" name="1.520000e+01"/></Assert> <Assert name="mapDepth"><value type="float" name="30"/></Assert> </Goal>
And send it in the pipe :
[dorado1@trex2 missions] *cat goal.sbd > msg.timing.1.cfg
 | this has to be done relatively quickly to avoid to miss the only communication window in msg.timing.1 |
then check that the goal has been correctly collected and dispatched before the end of the mission. You should see a message similar to this in TREX.log
[downlink][<number>]Dispatching Front.Info(<a number>)
[exec][<number>]Request received: ON front REQ Front.Info(<a number>)...
